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ABSTRACT 



A software analysis system for capturing tags generated by 
tag statements in instrumented source code. The software 
analysis system includes a probe that monitors the address 
and data bus of the target system. When a tag statement is 
executed in the target system, a tag is written to a predeter- 
mined location in the address space of the target system. The 
tag contains a tag value that is indicative of the location in 
the source code of the tag statement generating the tag. By 
monitoring the predetermined address, the probe is able to 
capture tags as they are written on the data bus of the target 
system. By properly instrumenting the source code, the 
software analysis system is able to perform a variety of 
analysis functions in essentially real time, including code 
coverage, function and task execution times, memory 
allocation, call pairs, and program tracing. 

26 Claims, 16 Drawing Sheets 
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METHOD AND APPARATUS FOR Although instrumented code is often a useful technique 

ANALYZING SOFTWARE EXECUTED IN for analyzing the performance of software in a general 

EMBEDDED SYSTEMS purpose (i.e., "host") computer system, it is less suitable for 

analyzing the execution of software in an embedded system. 

CROSS-REFERENCE TO RELATED 5 A* 1 embedded system is a system whose primary purpose is 

APPLICATION to perform a specific function rather than to perform general 

computational functions. For example, a microprocessor- 

This application is a continuation of U.S. patent applica- based microwave oven controller, a microprocessor-based 

tion Ser. No. 08/526,709, filed on Sep. 11, 1995 now U.S. automobile ignition system, and a microprocessor-based 

Pat. No. 5,748,878. 10 telephone switching system are all embedded systems. 

Embedded systems do not lend themselves to instrumented 

TECHNICAL FIELD co d e for several reasons. First, embedded systems generally 

™ . . i . * r*, i j „ do not have mass storage devices, such as disc storage, to 

This invention relates to software analysis, and more t , _ B ' „„ . i 

*r i • j store the result of tag statement executions. While the result 

particularly to a method and apparatus for analyzing a wide " . 5 , . . i . 

■ * c •* ■ c « j u jj a k of executing a tag statement can be stored in on-board 

variety of catena of software executed on embedded sys- 15 6 6 

tems random access memory, it is often difficult to externally 

retrieve such information. Furthermore, storing the results of 

BACKGROUND OF THE INVENTION statement executions in system memory consumes sys- 
tem memory resources thus preventing the target from 

Software is being written to control the operation of 2Q executing the software in a normal manner. It is generally 
processors, including microprocessors, in a wide variety of desirable to test the performance of software in an embedded 
fields. As software becomes more complex and lengthy, the system under the same conditions that the software will 
probability of software errors or "bugs" increases. normally run. Thus, an ideal software analysis technique 
Furthermore, the difficulty of finding software bugs would be "transparent" to the target system and thus have no 
increases with this increased length and complexity of 25 effect on the manner in which the target system executes 
software. While bugs that prevent execution of the software software. For these reasons, instrumented code is generally 
will be apparent, other types of bugs merely effect the not suitable for analyzing software in an embedded system, 
performance or efBciency of the software without preventing i n addition to software-based software analysis tech- 
its execution. Software bugs that merely effect the execution niques (e.g., instrumented code), hardware-based techniques 
of the software may easily go undetected, thus indefinitely 3Q have been developed to analyze software executing in 
impairing the efficiency of the software. For example, soft- embedded systems. For example, logic probes have been 
ware may allocate memory resources in an inefficient man- placed on the address and data bus lines of microprocessors 
ner thus preventing the software from running at optimum m ^ attempt to observe the execution of software in 
speed. However, since the software continues to execute, the embedded systems. However, it is very difficult to monitor 
existence of these memory allocation errors will not be 35 the execution of software using logic analyzers, and the lack 
apparent. 0 f aQV data reduction on the output of the logic analyzer 

A number of techniques have been developed to analyze makes this technique very time-consuming. Furthermore, it 

the performance of software in an attempt to find software is not always possible to determine which instructions are 

bugs, including software bugs that merely effect the perfor- being executed using the logic analyzer. For example, pro- 

mance of the software execution. One traditional technique 40 cessors executing instructions from internal cache memory 

is instrumented source code in which executable tag state- cannot be monitored using a logic probe because the execu- 

ments are inserted into various branches and locations of tion of these instructions is not reflected on externally 

source code, thereby "instrumenting" the source code. After accessible busses. 

the source code has been compiled and linked, the tag Another hardware-based technique for analyzing the per- 
statements are executed along with the code. As each tag 45 formance of software in embedded systems uses an emulator 
statement is executed, it performs an operation that can be in connection with instrumented code. Basically, this tech- 
either detected by an analysis device or recorded for later nique uses an emulator to monitor the execution of tag 
examination. For example, each tag statement may write a statements thus eliminating the need to consume system 
value to a respective address so that the identity of the memory resources and providing a means to extract tag 
address containing that value provides an indication of 50 execution data. One example of this approach is described in 
which tag statements were executed. As another example, U.S. Pat. No. 4,914,659 to Erickson. As described in the 
each tag statement may print tag identifying data to a disk Erickson patent, tag statements are inserted in the source 
file. As still another example, an array can be reserved in code and executed in an emulator connected to the target 
memory, with each array element corresponding to a tag system. Each of the tag statements writes a variable to a 
inserted in a respective location in the source code. As each 55 respective unique address. The emulator monitors the 
tag is executed, it sets a corresponding bit in the array. One address bus of the emulated processor to detect addresses on 
approach to analyzing software with instrumented code is the address bus corresponding to the respective tag state- 
described in U.S. Pat. No. 5,265,254 to Blasciak et al. ments. While the approach described in the Erickson patent 
Using instrumented code, a wide variety of software does extract the tag execution data without consuming 
parameters can be analyzed. Not only can instrumented 60 system resources, it nevertheless suffers from a number of 
source code allow one to determine which branches have limitations. For example, by requiring that there be a unique 
been executed, but it can also determine the execution time address reserved for each tag statement, overlay memory 
of a branch or function by placing executable tag statements techniques must be employed and a substantial amount of 
at the entry and exit points of the branch or function. When the target system's address space is consumed, 
these tag statements are executed, they generate respective 65 Another hardware approach to analyzing software execut- 
tags which are time stamped so that the elapsed time ing in an embedded system is described in U.S. Pat. No. 
between executing the tag statements can be determined. 4,937,740 to Agarwal et al. The Agarwal et al. patent 
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discloses a software analysis system in which a hardware 
probe monitors the address bus of the target system to 
capture addresses. The system disclosed in the Agarwal et al. 
patent includes an internal tag generator that generates tags 
when respective addresses (up to 256) selected by the user 
are captured by the probe. Since the Agarwal et al. system 
does not use instrumented code techniques or otherwise 
correlate tags generated from the captured addresses with 
respective software locations, the Agarwal et al. system does 
not provide easy to use and understand information about 
the execution of the software. 

There is therefore a need for a method and apparatus that 
can analyze the execution of software in an embedded 
system without the requirement that the embedded system 
have on-board data storage and/or output port capabilities in 
a manner that does not consume system resources, including 
memory, processor time and I/O resources, of the target 
system. 

SUMMARY OF THE INVENTION 

The inventive method and apparatus analyzes embedded 
software being executed in a target system having.a.data bus 
and an address bus. A plurality of executable- tag statements 
are .first inserted in the ^source code. Each of the tag 
statements, when executed, causes the target system to write 
a tag to a predetermined location in the address space of the 
target system. The tags contain respective tag values so that, 
by the proper placement of tag statements in the source code, 
the tag values identify the respective locations in the source 
code of tag statements generating the tags. After the source 
code has been instrumented, it-is compiled to obtain object 
code which then executes 7 in the target system. During 
execution of the object code, the address bus of the target 
system is monitored to detect when the predetermined 
location in the-addrcss-spacejjf jhe target system is be ing 
addressed. The da ta bus of t he target system is also mo\u- 
tored to capture a tag on the data-bus when-addressingof the 
predeterminediocation is detected. Based on the respective 
tag values of the captured tags, the inventive method and 
apparatus is able to determine the source code locations that 
are being executed. 

The tags generated-by-respective-tag-statements-can-be of 
two-t ypesri-cT T^^ nUol ta gs jmd__da_ta_tags. JCfontrol^tags 
include a data field having a tag value corresponding to the 
location in the source code of the tag|StatemejiUge^^^ing 4 
the tag, as explained above. Data4ag^^^^^y|^^^eaaie*6^ — * 
with a specific control tag^and^frTey have a-data- field that 
proy^^jnformation^about an event identified by the control 
) tag with whicryys_ass^ate^rC6^ 
: iAgMgg ^^ ^Mhat idelntifies^he analysisfiinction-for which 
the tag is used. 

The inventive method and apparatus is able to performs 
wide variety of software analysis functions. f Wifprm ance 

~~ Ind 



analysis can be accomplished by [recording firsrani 
times when respective first and seeondHags w are w presem on^ 
the data~bus:-The"first-and-seco nddtags~have" resDective tag"" 
values corresponding to the 1 o ca t i on~ir^Ke~s6uree- co de of 
first and second tag statements generating the first and 
second tags. Based on the difference -be tween^the^first and 
second times, the time required to exe^Se the^pfty/are 
between the first and second locations is determined^- ^ 

-Memory allocation .analysis can ' be accomplished by 
inserting control tag statements^) the source code at a 
locations that will cause them tc^be executed along with 
memory allocation statements. An executable^datir tag state- 
ment is also inserted along with each control tag to 1 write a 



data tag to a second predetermined location in the address 
space of the target system. The data value of the data tag 
indicates the memory being allocated by the mem.oryjdlo- 
cation statement. The_invenUve^r£elfe^and^paratus 
detects_wj^,the_se^n^pi^ete 
addres£jpace-df~tiie^a^ 

cap_ture_data tags-on r the ^aT OmsT ThlTmemory, jtllo cation 
resulting^ from &e~m effia m 

determinedbased on'the da ta values of th ecaptured data tag/j 

^Function-hnkmg'ca^be^nalyzed by~inserting^ag state- 
ments in the source code at locations causing respective tag 
statements to be executed along function call statements. 
Based on the order in which the tags are captured when 
addressing of the predetermined location is detected, the 
inventive method and apparatus determines which functions 
of the source code are linked to other functions of the source 
code. 

The inventive method and apparatus performs code cov- 
erage analysis by inserting tag respective statements in basic 
blocks of the source code so that the tag statements will be 
executed along with the basic blocks. Based on the tag 
values of the tags captured when addressing of the prede- 
termined location is detected, the inventive method and 
apparatus determines which basic blocks of the source code 
have been executed. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is an isometric view of a preferred embodiment of 
the inventive software analysis system. 

FIG. 2 is a schematic and block diagram of the software 
analysis system of FIG. 1 and its manner of use. 

FIG. 3 is a more detailed block of the software analysis 
system of FIG. 1. 

FIG. 4 is a block diagram of the communications and 
control circuit shown in the block diagram of FIG. 3. 

FIG. 5 is a block diagram of a data reduction processor 
shown in the block diagram of FIG. 3. 
FIG. 6 is a block diagram of a tag buffer shown in the 
40 block diagram of FIG. 3. FIG, 7 is a block diagram of a tag 
preprocessor shown in the block diagram FIG. 3. 

FIG. 7 is a block diagram of a tag preprocessor shown in 
the block diagram of FIG. 3. 

FIG. 8 is a screen display of the command window for the 
software analysis system of FIG. 1. 

FIG. 9 is a screen display showing the results of two 
different types of software performance analysis performed 
by the software analysis system of FIG. 1. 

FIG. 10 is a screen display showing the results of a 
memory allocation analysis performed by the software 
analysis system of FIG. 1. 

FIG. 11 is a screen display showing the results of a call 
linkage analysis performed by the software analysis system 
of FIG. 1. 

FIG. 12 is a screen display showing the results of a code 
coverage analysis performed by the software analysis sys- 
tem of FIG. 1. 

FIG. 13 is a screen display showing another presentation 
of the results of a code coverage analysis performed by the 
software analysis system of FIG. 1. 

FIG. 14 is a screen display showing the results of a high 
level trace analysis performed by the software analysis 
system of FIG. 1. 

FIG. 15 is a screen display showing the results of a more 
detailed trace analysis performed by the software analysis 
system of FIG. 1. 



60 



65 



08/06/2003, EAST Version: 1.04.0000 



6,161,200 



FIG. 16 is a screen display showing the results of another 
more detailed trace analysis performed by the software 
analysis system of FIG. 1. 



DETAILED DESCRIPTION OF THE 
INVENTION 

One embodiment of a software analysis system 10 in 
accordance with the present invention is illustrated in FIG. 
1. The system 10 includes a probe tip 12 that clips onto the 
microprocessor of a target 'system (not shown) in a conven- 
tional manner. As a result, the exte rnal connecto r pins of the 
target system. microprocessor.^iMudiag^^ 
address bus, are accessibl£jjo^^ 
is connected through a conventional^bobiP^ 
a probe chassis 20 cxm^mm^TO^^OSl^^cTromS for the 
system 10. The probe chassis 20 is, in turn, connected 
through a suitable cable 30, such as an Ethernet cable, to a 
host system 40. The host system 40 is essentially a conven- 
tional computer having a processor chassis 42 with a disk 



cessing routines 72 also receiv«4rIets^nbol database 65 so 
that the tag execution data in the data files 74 can be 
correlated with the location of the tag statements in the 
source code 65 in-order to proyide-reports-ajjo^dis^ays that 
5 specify perform anee4u-te i rffl£u^sourc^^jdeJoeafwns and 
branches. The symboLdatabase ~65 is pre ferablL loaded into 
the host through the disJTllrive 44 .(FIGr^j. Tie host 
application software 70 aho~incluJe^^ta^stmctiu%76 for 
storing^andhandlmg-the-analysisidata, and*c?!n%nWications 
20 s oftware— 78-forr proyiQ^ target 
access-probe_20 — — 

Inj^pefationT^aBh of the tag statements 62 generate a 
respective~tag containing a data field having a "tag value" 
that is generally unique to the location of the tag statement 
15 in the source code 60. Thus, for example, a first branch may 
contain a tag statement having a tag value of 1. A second 
branch may contain a tag statement having a tag value of 2, 
and so forth. When the tag statement 62 is executed by the 
target T, a processor in the target T writes a tag containing 



drive 44, a CRT monitor 46 with a display screen 48, and a 20 the tag value to a predetermined location in the address 
keyboard 50. The host system 40 preferably uses a Unix® or space of the target system T. As explained in greater detail 
Windows® user interface and operating system. Application below, the tag 62 may also contain at least one other field 
specific software is loaded through the disk drive 44 to cause providing information about its function or location of its 
the host system 40 to properly interface with the probe associated tag statement 62 in the source code 60. More 
chassis 20, receive appropriate configuration and operating 25 specifically, the tag statement 62 preferably writes a tag 
commands through the keyboard 50, and display analysis consisting of 32 bits which includes not only a data field 
results on the screen 48. word having a tag value, but also a number of bits which 

The use of the software analysis system 10 is illustrated define the type or category of tag. For example, different tag 
in FIG. 2. Source code 60 written to run on a target system types may identify function entry and exit points, branch 
is first instrumented by inserting tag statements 62 in the 30 points, and memory allocation statements. Tags having a tag 



source code 10 at various locations that the user is interested 
in analyzing. For example, if the user is interested in 
determining code coverage, the user will insert a tag state- 
ment 62 in each branch of the source code 60, and the system 
10 will determine which of the branches have been executed 
based on whether each tag statement has been executed. 
Other analysis functions are described in detail below. The 
insertion of tag statement 62 in the source code 60 results in 
instrumented source code 64. When the instrumented code 



type field to identify_^e_tag-type-are"icnOwn i "as""control 
tags J!J^jtie^refcr red-e mboGUm ^trof ~ffiersystem~%)^ all 
^control4ags -are-written,to, the .same, locatio n in the, address 
space of the target. In addition to control tags, the system 10 
35 also utilizes data tags. Data tags accompany control tags and 
are writtetrto a second -location in the address space of the 
target^o-proviHe-additionaf information relevant to a par- 
ticular control tag. For example, a control tag may indicate 
that a memory allocation is taking place, and two data tags 



64 is produced, a symbol database 65 is also created which 40 accompanying the control tag may indicate the size of the 

provides a record correlating each of the tag statements to memory allocation and the memory pointer associated with 

their locations in the source code 10. The instrumented that allocation, respectively. Since only a single location in 

source code 64 is compiled in a conventional manner at 66 the address space of the target system preferably is used for 

thereby resulting in executable code 68. The executable code control tags and a relatively few locations used for data tags, 

68 is then loaded into the target system T by any suitable 45 the inventive system 10 does not significantly use the 

means. For example, the executable code may be stored in memory resources of the target system, thus making the 

a programmable read-only memory ("PROM") that is analysis system substantially transparent to the target sys- 

installed in the target system T. The executable code 68 may tem. 

also be executed in the target system T through a conven- The probe tip 12 monitors the address bus and the data bus 

tional emulator (not shown). Regardless of how the execut- 50 of the target T and determines when the processor addresses 

able code 68 is loaded into the target T, the target T is then the predetermined location(s) in the addre ss space of the 

allowed to execute the code. The probe tip 12 clips on to the target s y^!£ n l3«33^ 

target system T in a conventional manner to make electrical currently on the aalFousvAs a result, ^e^uu^^^ptSed 



contact with at least t he addres s_busand.the-databus"of thj 
target system T. Tags _ge nerated _by-the-execution-of ti 
statements 62-and coUected by the probTtifTale~tFansfei 
to the>probe.chassis r-20 7 thrbugh the ribbon~cableA8 v After 
proD€-chassis:2Q:has-performed vanous tabulatip^ano^ 
redu ction -functions on^th'e d ata~fjro^lhe_rjrpb4 JtipHB 
oulputsrappropriMeI<iata-to-the J "riost s ystem 40 through 
locaLarea.network^cable^O^Hosrap 
includes~prpc«ssmg-routines 72 that store ^ataSa^ 
retrieve^ata-fromrdata^les-74^an^ 
software 70 also-includes a gfa'pm^afifeer InterlScevif*^ 



tag-valueindicateVth^location^^ 
"55 being executed £Mo^>yj£_jhe^ the 
execution of the software jnj^targerT'in^essentially^reaU 
time since the probe 20 receiye^^ehftof th^ta^valueTasiM 
is captured and performs various^functions^using the tag"! 
value. For example, for some software analysis functions;-^ 
60 the probe 20 associates an execution time with the tag value 
so that the execution time between a pair of tag statements 
can be determined. The probe chassis 20 may also perform 
various data reduction operatior^o^the-tag-valUe7such~asr^~ 



_ f fai^xjmiple 1 -call-pair-analysis~^^ 

as the X-ll or Microsoft WindowsCS* interface, tha tjpyjofks 65\(fujicttons that are^cjllej|v*b*y- other- functions) allocation, 
with the processing routines 72 to ogexate-on~the~cfata filesF}> Ba1>ica1^lhe~s^ 
74 (ajad^provide--^^ and task execuuon^timej^ 
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portions of the source code executed or not executed, The tag buffer 112 is a high speed buffer that temporarily 

memory allocation analysis (i.e., identifying how much stores the tags received from the tag preprocessor 100. The 

memory each allocation statement in the source code alio- tags are then passed on to a data reduction processor 114. 

cates and identifying specific allocation errors), and program The tag buffer 112 is used to accommodate tags received in 

tracing (i.e., creating a sequential history of the execution of 5 bursts at a much faster rate than can be handled by the data 

the source code). Once again, the probe chassis 20 performs reduction processor 114. The tag buffer 112 can accommo- 

these functions in essentially real time. Finally, the probe date high speed bursts of tags from the tag preprocessor 100 

chassis 20 communicates with the host 40 to upload the data as long as the average rate of tags passed by the tag 

and-allow it to be displayed by the host. preprocessor 100 does not exceed the processing rate of the 

Llhe^software analysis system^l0~of~FIGSr4,and. 2 is 10 data reduction processor 114. 
showthin greater'detail-m'ttie^c^ The communications and control circuit 120 is illustrated 
reference to"FIG737tBe~probe tip 12 includes a conventional in greater detail in FIG. 4. The interface between the probe 
LCA commercially available from Xilinx that is pro- chassis 20 and the host 40 consists of a standard Ethernet 
grammed by information downloaded from the host 40 communication channel. TheJ^ernet-transmission~status 
through the probe chassis 20 to monitor one or more 15 signals are routed through a\communicj^ns_portJ30^ v ^a 
predetermined addresses on the address bus. When the probe status.port J32.JITie_comjmmications port 130 is preferably 
tip 12 detects that one of the predetermined addresses is implemented- witrra-Motorola-Mfc68340 control processor, 
active, it clocks the tag on the data bus into the probe tip 12. As explained in greater detail below, a control processor 
As the probe tip 12 must interface with a specific micro- 134 handles commands from the host software and initial- 
processor used by the target system T, the probe tip is usually 20 ization of the probe chassis 20. The control processor 134 
specific to the particular microprocessor used by the target also has direct access to the communications port 130 and a 
T. However, the probe tip 12 is the only target processor control memory 136. The control processor 130 is preferably 
specific portion of the system 10. The probe tip 12 preferably an MC68340 microprocessor. The control memory 136 
also monitors the status bus of the probe tip 12 so that it can stores the instructions for the control processor 134 software 
detect a write function to one of the predetermined 2 5 as well as data storage for the control processor 134. The 
addresses. control memory 136 is preferably non-volatile memory, 

jWhen Jhe probe tip 12 capti^s.ejic^Ja^it^assesLthe^ag^ such as flash memory for code storage and DRAM for data 

to a tag^reprocessor-lOOTwliicrralso receives a time stamp storage. As explained in greater detail below, the control 

from a time stamp generator 102. The tag preprocessor 100 processor 134 has dual port access to the database memory 

pairs the current time stamp value from the time stamp 30 H6 anc * database 110 to transfer data to the control memory 

generator 102 with the tag values received from the probe tip 136. 

12. It also determines where the time stamped tag values are The data reduction processor 114 is illustrated in greater 
to be routed based on the tag type. As explained above, the detail in FIG. 5. The data reduction processor 114 includes 
tag type is defined by the value in the tag type field in the tag a data reduction microprocessor 140 having a data bus 142, 
received from the probe tip 12. More specifically, if the tag 35 an address bus 144 and a control and status bus 146 
is a coverage analysis tag generated by a tag statement connected to the data base memory 118 (FIG. 3). The data 
placed in a branch of the source code to determine if the reduction microprocessor 140 is also connected to data and 
branch is executed, the tag is passed directly to a code code storage memory 150, the tag buffer 112 and an I/O port 
coverage data reduction processor and database 110. All tag 160 through these busses 142, 144, and 146. The data 
types other than coverage analysis tags are passed to a tag 40 reduction microprocessor 140 processes tags from the tag 
buffer 112. It is desirable to process the code coverage tags buffer 112 (FIG. 3), as explained above, under control of 
separately from the other tags because coverage tags are instructions from the code storage memory 150. The data 
generally far more frequent than other types of tags. The tag reduction microprocessor 140 also communicates with the 
preprocessor 100 also preferably performs some qualifica- control processor 134 (FIG. 4) using the I/O port 160, and 
tion on the tags before passing them to the tag buffer 112 or 45 a decoder 132. The control processor accesses data in the 
code coverage data reduction processor and database 110. data base memory 118 through the 1/0 port 160 under the 
More specifically, the tag preprocessor 100 preferably control of the DMA and interrupt channels of the data 
passes only the tags for the measurement being performed to reduction microprocessor 140. The DMA channel of the data 
minimize the number of tags that must be processed and reduction microprocessor 140 transfers data to or from the 
thereby maximize the speed of downstream circuitry. The 50 data base memory 118 and to or from the I/O port 160 each 
tag preprocessor 100 is preferably implemented using a time the control processor 134 reads from or writes to the 
conventional LCA commercially available from Xilinx that I/O port 160. This provides the control processor 134 dual 
is programmed by information downloaded from the host 40 port access to the data base memory 118. As a result, 
through the probe chassis 20 to perform the functions relatively inexpensive DRAM may be used in the data base 
described above. _____ — ■ — — — — memory 118 as dual ported memory between the data 
pThexode.coveragellatTreduction processor.and5atab®iA reduction microprocessor 140 and the control processor 134. 
110^ipreferably*a*hard-wife^ Furthermore, the control processor 134, which is relatively 
be implementednusuTg^a microprocessor and " ; ^^feiated slow, is able to effectively access the data base memory 118 
circuitry. The code coverage data~reduction ^c^ess©Mai(d. using only a single bus cycle of the data reduction micro- 
database 110 converts eapturealcode-coverage'tags"to|ifidi- 60 processor 140 and minimizing the delay to the data reduc- 
ces in a code coverage^ata-base-arT4y.-Each-bit-m-theSray tion calculations. 

represents a single tag value^rresppnding-to the-location in The data reduction processor 114 performs most of the 

source code 60 in which-the-cc^espondmg4a^^3^ments functions in the probe chassis 20. The data reduction pro- 
were inserted at 62 (FIG. 2).^Thus,4he-conteritsjdftfcj^g^ cessor 114 processes tags from the tag buffer 112 and stores 

which may be downloadedSo-the-hosr^Or provides~an 65 resulting data in structured form in a database memory 118 

indication of all instrumented branches of the source code for various types of performance analysis such as memory 

that have been executed. allocation, execution time, real time trace, etc. Thus, the 
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database memory 118 stores data resulting from the capture 
of all of the tags.other,than : code coverage tags^By^extractihg 
and saving pertinent data from th e tagsand-then-discarding- 
the tagsrthe-req uired "ca pacity ofTtfie ^database^memorv-llfo 
can*be-relalively_smaU._Also,-the 5 
is de^mjentlonly^ pn the nu mber of functions or task 
instancesxbeing monitored and not The numbeTl)f n^igsjp 
receiyea^onT^ As a result-of-the-databasey 

]stnJcluli~(i^eT7the size of the dataJbase^^^^^naLtoJhe 
number^f^events monitore^rTtn^^man^r^^^^^^f 
occujrence>of.such_ew program 
Jean nin~foTlfrrindenmte_p^ 

softwareis-adequately teste^arTdlyetlno data is missed, i.e., 
the measurement is non-sampled. 

In order for the data reduction processor 114 to make 
meaningful measurements of an embedded software 
program, it must track the software execution context. Since 
most modem embedded programs use some kind of real- 
time operating system ("RTOS"), this means that the data 
reduction processor 114 must be aware of the RTOS execu- 
tion context. 

Three events which are controlled by the RTOS must be 
tracked: when a task is created, when a task is deleted, and 
when a task switch (swap) occurs. In order to accomplish 
this, a second instrumentation step (beyond application 
program source instrumentation) is required. Most modem 
commercial RTOS provide call outs which conveniently 
allow a user supplied software fimction-to-execute4yhen_a 
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'frozen", as described for task Y above. The data reduction 
)rocessor 114 then points back to Y's stack, and the appro- 
priate timers resume counting time where they left off. Since 
the function hierarchy context of task Y has been preserved 
on Y's stack, the system is able to accurately track the 
continuation of task Y's activity. When a "delete task" tag is 
received, any execution information preserved on the task's 
stack is tabulated a final time in the appropriate data base. 

This context tracking method enables many sophisticated 
qualifications of program measurements based upon soft- 
ware execution context. Performance measurements may be 
qualified such that function execution time is tracked only 
when the program is executing a particular task, thereby 
eliminating executions from a different context of functions 
shared between two or more tasks. While performance 
measurements have been described as a typical example, 
other measurement qualifications are equally possible and 
desirable. For example, a trace history measurement can also 
be qualified by the software context such that tags will only 
be stored in the trace buffer when executing in a particular 
task, or a particular function nesting hierarchy. Memory 
allocation could be tracked only when the program is 
executing in a particular task context, etc. 

The data reduction processor 114 performs call pair 
measurements by tracking which functions called other 
functions by identifying consecutive function entry tags 
generated by respective tag statements in the source code for 
the calling and called functions. The data reduction proces- 



specific^CTOSjy^n^ sor 114 updates this information each time a new function 



the appropriate_call outs for th e ab^Dve^three~RTOS"ev e J| Bts 
outputs^thf^prgjria itercoritfol-tag-tO'indicate^the-kmd-of 
RTO'S/eve^n^^ 

RTOSlnay"be"e~asily < modifiej^o H emit the appropriate tag as 
well. 
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depending upon wKicrTRTOS tags are received. When a 
"task create*' tag is received, therdata^reduction processor 
114 establishes in memory a stack area for the task. When a 
"task delete" tag is received, tr js^ata-re duction processor 
114 deletes the stack after tabulating any remaining^mea- 
surement results into the appropriate data baseJWhen a "task 
Ysv^tch*l_.tag,is_received,-the-data^reducti6h processorTl4 
suspends-any~measurement-activity~f6rgthe current task 
stack, and switches to another stack which corresponds to 
the task ID received (as a data tag! ^ _ 

The data reduction-proccss or 114 also tracks co ntext at the 
function level~within~each task using tags emittedl^each 
function entry and exit point. When a switch to a task occurs, 
the data reduction processor 114 will receive a function 
entry tag from the first function in the task, and will record 
the entry on the stack^e.g.-function "A"). If a second 
function ("8") entry tagjsj yceive^ljrioj^ Mhe^xirt^ for 
function A, function B's entry tag is recorded^HTthe^ack, 
and the data reduction processor 114 "knows" that a function 
nesting has occurred, i.e. A has called B. For performance 
measurement purposes, the time stamp corresponding to 
each tag is recorded on the stack as well. 

When a context change occurs such as a task swap (e.g., 
from task "Y" to task "Z"), the current time is recorded on 
Y's stack such that no further execution time will be 
attributed to it while the program executes other tasks. The 
data reduction processor 114 then switches to the stack 
corresponding to task Z and begins tracking time for each 
tag emitted while executing task Z. Should the RTOS swap 
back to task Y, the times and function nesting of task Z are 
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entry tag is received. The resulting data can be stored as 
either a count of executions of each call pair or a flag 
indicating at least one execution of each call pair. 

Finally, the data reduction processor 114 performs 
memory allocation measurements based on receiving from 
the tag buffer 112 memory allocation tags generated by tag 
statements inserted into allocation statements in the source 
code. These memory allocation tags (including control tags 
and data tags) indicate how much memory was allocated or 
freed by each call to a memory allocation function. 

The design goal for memory allocation tagging is to 
record successful allocations and deallocations, including 
the original allocation size and site (caller identifier), and 
allocation errors, including block overwrites, block under- 
writes and heap corruption (i.e. writes out of bounds 
references), writes to deallocated blocks, and erroneous 
arguments to interface routines (e.g. wild pointers). 

Implementing memory allocation tagging includes an 
error-checking memory allocator and an instrumented inter- 
face to it, a set of instrumentation rules for modifying user 
code, and a set of replacements for the standard memory 
allocation routines. The error-checking memory allocator is 
based on a straight forward heap-based memory allocator. 
The interface to the allocator is based on the standard 
memory allocation routines, augmented with the addition of 
a memory management tag (e.g. augmented-malloc). The 
tag encodes the kind of the memory [deallocation call (e.g. 
malloc, realloc, free, etc.), and the caller identifier. Infor- 
mation about each allocation is kept, including the requested 
size and the caller identifier of allocation site; for later 
reference when the block is deallocated, or an error is 
discovered in the block 

When a block is successfully allocated, a data and control 
tag are written to announce the allocation, including the size 
for the allocated block (a data tag), and the kind and caller 
identifier of the allocation (a control tag). When a block is 
successfully deallocated, a data and control tag are written 
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similar to that for a successful allocation, including the size buffer 112 illustrated in FIG. 6 is able to effectively imple- 

for the allocated block, the kind of the deallocation, and the ment a large capacity, high speed FIFO buffer using a high 

caller identifier of the allocation. speed, low capacity FIFO buffer 170 of conventional design. 

The base allocator is augmented with error checking. ^ FIF0 bu ?" X ™ "T^, Ieoeives . from "V* 8 

including verification of the arguments to the allocation and 5 preprocessor 100 (FIG. 3) and sequentially outputs those 

deallocation routines, the integrity of each block present in t0 the microprocessor ™>-™e microprocessor 140 

the heap, whether currently allocated or freed, and the «l»n aores tb _, e ta S s m,he DRAM 150 while awaiting data 

integrity of the heap as a whole. When an error is identified, reductl0n , and Processing^ However, mt^eyent-UjaWhe 

a set of data and a control tag are written to indicate the error. nJt^&^m^S^t^boOt^^^m^ it 

The information present in the tags include an error io outpaUs a bit to the direct mem^ryjiccess^DMA ) input of 

identifier, the address of the block in error and its size (if th f mlc [°P'° c r « s ? r J 40 ; ^jn«croprocessor-140 then 

any), the caller identifiers) of the block's aUocator and Mows H FO buffer "° to ™ te data t0 the 

deallocator (if any), and the kind of allocator call begin £RAM 150, thereby speeding up the writing of data in the 

attempted when the error was discovered. likam isu. 

Instrumented C code, which calls the standard memory " t M mentioned above, the tag preprocessor 100 combines 

allocation routines, is changed to replace the original calls me ^ t?*™* from thc P robc b P " ^ * Umc s 

with calls to the corresponding instrumented interface, recei^d tarn the Ume stamp generator 102 and routes them 

which allows for the addition of a memory management tag, to Clther ; he d f rcduc,lon P race ^ r " 4 " „ m ° 

as described above. Uninstrumented C code, which calls the covcra 8 c data 5^™ P roccssor and databa f c """Vf 

standard memory allocation routines (e.g. precompiled ™ preprocessor 100 is shown m greater deM m FIO^-A- 

libraries), is provided for by a set of routines with the same <^^A^«^^^S!^!^^^ stam P/ 

signature as The standard routines, but which call the corre- generator-lO^FIGr^^^ 

spending instrumented interface, and pass an "unknown" P robe ^UzndjontoLbte data,^u^pn| 

caller identifier processor— 114. Jhe„cJock^and^j &ntM^ 

, , _ _ , ., , 25 controls the operation <of other-components^in'thc-tag-pre- 

In addition to the provisions made for C code as described ^ m ^ ^^^400 includes a tfobejift 

above, mstrumented C++ code must also handle the use of la toh - 18 2^hat- wheD^^ 

the global versions of operators new and delete. circ^itlS^hlsln^^ 100 the tag type 

For instrumented C++ code which calls the default opera- field and the tag V alue. r Based~on-th~eTa]^ 

tor new, a file local definition is supplied, using placement 3Q cove rage tag splitter 184^routesnhenag;toreithe1-tlielcode 

syntax, which augments the standard operator new signature coverage data reducdon^rocessor^nddatabase llQ^ldta) 

with a memory management tag argument Uses of the via bus 188 or to a tag m OTpk^l90-via^uil9l. Tfirtag 

default operator new are replaced with calls to the aug- preprocessor 100 also mcludeTa^rlnl^ 

mented version, whose definition simply calls the instru- mat can apply an internal tag to tBe^ multiplexer490;The ~ 

mented interface to the allocator (i.e. augmented-malloc). 35 data re d U ction processor 114 contfolTthr tag multiplexer 

For uninstrumented C++ code, a default version of global 190 10 apply either the j nter nal tag on bus 196 or the tag from 

operator new is provided which calls augmented-malloc me probe tip 12 on bus 192 to the tag buffer 112 Finally, a 

with an "unknown" caller id. synchiatch4984atches4n4he4^ 

For instrumented C++ code which calls the default opera- time.unde r contr ol of the clock and=c6ntrol-drcuit38b^sa 

tor delete, a file local definition of the default delete operator 40 thaHhe-Jme stanipis synchronized to the current]y„capturedP 

is provided which does nothing. Calls the (now, do nothing) r^tagl^r — " 

operator delete are followed by a call to the instrumented Theuser interface for the host system 40 is best illustrated 

interface (i.e. augmented-free), along with an appropriate reference to the user interface comman d J?ar,sho wn in 

memory management tag. For uninstrumented C++ code, a piQ g During-the operationoftfie^Sw 

default version of global operator new is provided which 45 io j tne displayOTeen]4^nfie-monltoN 

calls augmented-free with an "unknown" caller id. a t | t i e b^230XrO}e^pen^ 

Returning to FIG. 3, the probe chassis 20 communicates bar 232 for entering commands into the^ystem^,10-is 

with the host 40 through a communications and control positioned below the title bar 230. Finall y, a t ool bar^234 

circuit 120. Under command of the host processor 40, the adapted to allow direct entry of commands avaflablein the 

communications and control circuit 120 can directly access so command bar 232 is positioned beneath the command bar 

data stored in the database memory 118 or the code coverage 232. Most of the file commands available in the command 

data reduction processor and database 110 so that such data bar 232 may be directly selected by clicking on appropriate 

can be transferred to the host 40 for further processing and icons of the tool bar 234 using a pointing device, such as a 

display. The communications and control circuit 120 also mouse. A new file icon 240 causes the system to save 

routes commands from the host 40 to thejjrobe chassis 20 55 unsaved data, closes any open views on the screen and 

to select the mode of probe operation, including specifying invokes a configuration dialog to allow configuring for a 

the function to be performed and the tag types to be new task. An 'open'* icon 242 invokes a dialog for loading 

collected. and displaying analysis results saved from a prior test A 

The tag buffer 112 (FIG. 3) is shown in FIG. 6 along with "save icon 244 invokes a file save dialog to save analysis 

its interface to the data reduction processor 114. As 60 data resulting from a test. The save command presumes that 

explained above, tags are often captured by the probe tip 12 the data has already been given a file name. If not, the file 

in bursts at rates that exceed the maximum processing rate save dialog requests the user to enter a file name under 

of the microprocessor 140. One apparent solution to aver- which file data is saved. A "Print" icon 246 invokes a print 

aging the tag capture rate is to use a first-in first-out dialog which allows the software analysis system to print 

("FIFO**) buffer. However, FIFO buffers capable of operat- 65 reports showing analysis data or subsets of data. A print 

ing at high rates of speed having sufficient capacity to store preview icon 248 allows the viewer to view on the screen 

large numbers of tags are relatively expensive. The tag how the printed document will appear. The user can exit the 
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Windows software by either doubleclicking on an exit bar and quickly operated by relatively inexperienced personnel. 

250 or selecting "exit" as a file command in the command A similar user interface running on UNIX® workstations 

bar 232. utilizing a X-ll windowing system provides similar ease 

The edit command in the command bar 232 consists of a anc * speed of use. 

single command, namely, a "copy" command. This 5 Examples of performance analysis displays are illustrated 

command, which can be entered by selecting a "copy" icon in FIG. 9 for both task performance and function perfor- 

260 in the tool bar 234 copies selected data into a clipboard mance. The function performance display 310 includes a 

(i.e., temporary storage) so it can be pasted into another first column 312 listing various functions performed by the 

application such as a spreadsheet program. source code followed by a column 314 showing the number 

Several run commands available from the command bar 10 of times each of those functions was executed. Time col- 

232 may also be entered through the tool bar 234. A "run" umns 320 men snow mc minimum, maximum, and 

icon 270 erases any previously acquired data and begins the average time, respectively, required to execute each of the 

acquisition of data from the probe 12 while performing an functions listed in the column 312. The cumulative time 

analysis function. A "halt" icon 272 halts data acquisition spent executing each of the functions (i.e., the product of the 

from the probe until a resume icon 274 is selected. There are 15 number of executions and the average) is then displayed in 

a large number of data commands that can be selected from column 322. Finally, column 324 displays the percentage of 

the command bar 232 or from the tool bar 234. A "sort um e that each of the functions listed in the first column 312 

ascending" icon 280 sorts in an ascending order active data w ere being executed. The data in column 324 can be 

acquired from an analysis by values in the selected column. calculated as the ratio of each entry in column 322 to the sum 

Similarly, selecting a "sort descending" icon 282 causes the 20 of the entries in column 322. 

acquired data to be sorted in a descending order. Selecting A task performance analysis display screen 330 is similar 

a "sort multiple" icon 284 invokes a sort dialog for setting to the function performance analysis display screen 310 and, 

up a multi-level sort. in the interest of brevity, its explanation will not be repeated. 

An "edit filter" icon 286 invokes a filter dialog for setting 2$ The performance analysis ratios shown in column 324 can 

up a data filter for an active view. Filtering a display causes also be displayed as a bar graph histogram, 

only selected measurement results to be displayed, i.e., only As explained above, the software analysis system 10 can 

the functions of interest. An "apply current filter" icon 288 also perform a dynamic analysis of memory allocation, and 

causes the system to apply a previously specified filter to the an example of the display of data from such analysis is 

active data view. A "show all" icon 290 removes the data 3Q shown in FIG. 10. A memory allocation screen 350 includes 

filter so that all of the acquired data is displayed in the active a first column 352 listing each of the functions containing a 

view. A "find" icon 292 invokes a find dialog for setting up memory allocation statement A second column 354 lists the 

a search within an active view. source file for each of those functions. The next column 356 

A variety of data commands can also be entered through iists tne number of times each of those functions were 

the command bar 232 or directly through the tool bar 234. 35 executed and the next three columns 358, 360, 362 lists the 

A "function performance" icon 300 is selected to invoke a smallest memory allocation, the largest memory allocation 

function performance table to display function performance and the average memory allocation, respectively. The final 

data that has been acquired from the probe or loaded from column 364 contains a bar graph and a digital display of the 

a file stored form a previous analysis. A "task performance" memory bytes currently allocated. By viewing the bar graph 

command can be selected from the view menu in the 40 in column 364, the operator can examine in essentially real 

command bar 232, but there is no corresponding icon in the time the allocation of memory in the target system as the 

toolbar. A"task performance" command displays previously software is being executed. Appearing with the memory 

acquired task performance data from either the probe or a allocation display 330 is a memory error display 370 that 

file. A "call linkage" performance icon 302 invokes a call lists each of the memory errors found during the memory 

linkage table to display call pair data from the probe or from 45 allocation analysis. 

a file of call pair data acquired in a previous test A "branch An example of a call linkage table resulting from a call 

coverage" icon 304 is selected to invoke a branch coverage pair analysis is shown in FIG. 11. A call linkage display 380 

table to display coverage data from the probe or from a file dynamically tracks a number of function linkages by listing 

saved from a previous test A coverage summary graph icon in a first column 382 the calling functions and in a second 

306 invokes a coverage summary graph to display a statis- 50 column 384 called functions. The number of times each of 

tical record of coverage data from the probe or from a file the calling functions has called the called function is then 

stored from a previous analysis. A "memory allocation" icon listed in a third column 386 in both digital and bar graph 

308 is selected to invoke a memory allocation table to form. 

display memory allocation data acquired from the probe or As explained above, the source code can be instrumented 

from a file saved from a previous test. Finally, a "trace 55 by placing a tag statement in each branch to assess call 

analysis" icon 310 invokes a trace view in the display coverage, i.e., the number of branches executed and the 

window to display trace data acquired from the probe or frequency of execution of each branch. An example of a 

from a file saved from a previous test. co a e coverage display 400 is illustrated h- FIG. 12. The 

The command bar 232 also allows standard Windows® code coverage display 400 includes a bar graph 402 showing 

commands, such as hiding or showing the tool bar 234, 60 the overall level of coverage achieved during a test. Func- 

cascading or tiling open view windows, arranging icons, etc. tions are categorized in percentile ranges along the vertical 

The tool bar 234 also includes an index icon 250 to invoke axis, and the number of functions that fall within each range 

a top level contents page for on-line help in operating the grouping is indicated on the horizontal axis. The total 

system 10 and a second "help" icon 232 which may be number of functions and tasks not executed are listed at the 

"dragged" and "dropped" to any item on the display to 65 bottom of the display at 404. This listing 404 can alert the 

obtain help about that item. Thus, the Windows® user operator to portions of the software that are apparently not 

interface allows the software analysis system to be easily being executed. An alternative code coverage display 408 
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consists of a line graph 410 depicting the percentage of 
coverage achieved over the period of time conducting the 
test, as illustrated in FIG. 13. The code coverage graph 410 
of FIG. 13 shows that 15% of the code was executed during 
the first minute, the rate of code coverage increased only 5 
marginally for the next two minutes, and the rate of code 
coverage then increased at a much faster pace for the next 
two minutes until leveling off at 40% coverage. 

The trace function as described above can be displayed in 
at least three different modes. A high level trace display 420 1Q 
shown in FIG. 14 is preferably the default view upon entry 
in the trace mode. The display 420 contains a time ordered 
list of nested function entry and exit points and RTOS task 
events. The display includes a column 422 showing the 
source file for the software, a column 424 showing the 
functions in the order that they are executed, a column 426 15 
showing a line number of that function, and a column 428 
designating whether the traced function was an entry or exit 
point. A relative time stamp for each function is listed in a 
right-hand column 430. Alternatively, the results of a trace 
can be displayed in a control flow display 440 shown in FIG. 20 
15. A control flow display shows time-ordered listing of all 
function points, executed branches and real time operating 
system events in the trace buffer. As with the high level 
display 420, the control flow display displays the source file 
in a first column 442, the tasks, functions, and branch points 25 
in the order that they are executed in a third column 444, 
whether the function is an exit point, an entry point, or a 
branch in column 446, and the line number of the point in 
column 448. As before, the right hand column 450 lists a 
relative time stamp for each point. Finally, the results of a 30 
trace can be displayed in a source view display 460 shown 
in FIG. 16. A source view display shows every line of 
executed software, although loops can be expanded or 
collapsed. The display 460 interpolates source lines which, 
by inference, were executed. This determination of execu- 35 
tion is made by retrieving those source code lines which 
comprise the basic block in which each branch tag is located. 
Function entries and exits, branches, RTOS events, and other 
executed lines of software of interest preferably may be 
color coded. As with the other trace displays shown in FIGS. 40 
14 and 15, the source view display 460 displays the source 
file in a first column 462, the functions in the order that they 
are executed in a third column 464, whether the function is 
an exit point, an entry point, or a branch in column 466, the 
line number of the point in column 468, and a relative time 45 
stamp for each point in column 470. 

It will be apparent to one skilled in the art that the various 
analysis functions that the software analysis system 10 is 
capable of displaying can be presented in displays other than 
shown in FIGS. 9-15. Furthermore, from the foregoing it 50 
will be appreciated that, although specific embodiments of 
the invention have been described herein for purposes of 
illusion, various modifications may be made without devi- 
ating from the spirit and scope of the invention. Accordingly, 
the invention is not limited except as by the appended 55 
claims. 

What is claimed is: 

1. A method of analyzing software being executed in a 
target system, comprising: 

inserting a plurality of executable tag statements at loca- 60 
tions in the software which, when executed, cause the 
target system to write a plurality of respective tags to at 
least one predetermined location in an address space of 
the target system, the respective tags containing respec- 
tive tag values corresponding to the locations in the 65 
software of respective tag statements generating the 
respective tags; 
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storing in a symbol database instrumentation data asso- 
ciated with each executable tag statement inserted into 
the software; 

retrieving tags during execution of the software from the 
at least one predetermined location; and 

determining, during execution of the software, the soft- 
ware locations that have been executed by using the tag 
values of the retrieved tags as keys for retrieving from 
the symbol database the instrumentation data associ- 
ated with each of the retrieved tags. 

2. The method of claim 1 wherein retrieving tags during 
execution of the software comprises: 

allowing the target system to execute the software; 

monitoring the at least one predetermined location while 
the target system executes the software; and 

capturing tags from the at least one predetermined loca- 
tion as the monitored target system executes tag state- 
ments. 

3. The method of claim 1, further comprising: 
maintaining, while the software executes, an output data 

set that lists each of the software locations executed and 
a number of respective times that the software locations 
have been executed. 

4. The method of claim 1 wherein at least one of the 
executable tag statements is inserted in the software at a 
software location that will cause the tag statement to be 
executed along with a memory allocation statement, and 
wherein the method further comprises: 

inserting an executable data tag statement in the software 
at the software location that will be executed along with 
the memory allocation statement, the executable data 
tag statement, when executed, causing the target system 
to write a data tag to at least another predetermined 
location in the address space of the target system, the 
data tag containing a data value indicative of a char- 
acteristic of the memory being allocated by the memory 
allocation statement; and 

storing in the symbol database the data value and instru- 
mentation data associated with the executable data tag 
statement. 

5. The method of claim 4, further comprising: 
detecting when the at least another predetermined location 

in the address space of the target system is being 
addressed; 

capturing a data tag directed to the at least another 
predetermined location when addressing of the at least 
another predetermined location is detected; and 

determining a memory allocation resulting from the 
memory allocation statement by retrieving from the 
symbol database the instrumentation data associated 
with the data tag by using the data value as a reference 
key for looking up the instrumentation data. 

6. The method of claim 1, further comprising: 
inserting executable tag statements in the software at 

software locations causing respective executable tag 
statements to be executed along with a plurality of 
function call statements; and 
determining which function call statements of the soft- 
ware are linked to other function call statements of the 
software based on the order in which the respective tags 
are retrieved from the at least one predetermined loca- 
tion. 

7. The method of claim 6, further comprising compiling 
a statistical record of the frequency at which specific func- 
tion call statements are called by specific calling functions. 
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8. The method of claim 1, further comprising: 16. The system of claim 12 wherein the tagging instru- 
establishing criteria for processing the captured tags based menter inserts at least one of the tag statements in the 

on their respective tag values; software at a tagging location that will cause the tag state - 

examining each captured tag to determine if the captured rnent to be executed along with a memory allocation 

tag meets the criteria; and 5 statement, and wherein the tagging instrumenter inserts an 

subsequently processing and displaying respective soft- executable data tag statement in the software at a tagging 

ware locations that have been executed based on the location that will be executed along with the memory 

captured tags only if the captured tags meet the criteria, allocation statement, the data tag statement, when executed, 

thereby filtering the captured tags after the captured 1Q caus i Q g the target system to write a data tag to at least 

tags have been captured. another predetermined location in the address space of the 

9. The method of claim 1 wherein the respective tags may m? lhe dala a data value indicative 

be either control tags or data tags, the control tags including c ,. T1 t , , „ 

« u . . ° , ° j . * il r* or the memory being allocated by the memory allocation 

a field having a tag value corresponding to the software , , . , . , / , 

location of a control tag statement generating the control tag, XJ statement, and wherein the tagging analyzer further com- 

the data tags being associated with a respective control tag pnses: 

and having a data field that provides information about an a memory allocation analyzer that determines the memory 

event identified by the control tag with which the data tag is allocation resulting from the memory allocation state - 

associated. ment based on the data value of the data tag captured 

10. The method of claim 1 wherein the instrumentation 2Q by me probe and maintains a miming account of the 

data includes the tag values. memory allocated by the memory allocation statements 

U. A system for analyzing a computer program executed , j 4 . . * , r j * . 

\ J . ■ r r ° based on the data values of respective data tags cap- 
in a target system, comprising: , , r to r 

tured by the probe. 

a tagging instrumenter that inserts a plurality of execut- ' „ 

fr * , * * u i • * *L * 17. The system of claim 16 wherein the memory alloca- 

able tag statements having tag values into the computer 2 s • , , . 

program at tagging locations and records instrumenta- Uon g enerates a S ra P h * essentially real time of the 

tion data related to the tagging locations; amount of memory allocated based on the running account. 

a symbol database that contains the tag values associated 18 ^ s y stem of claim 12 wherein the ta 8S in g instru " 

with the plurality of executable tag statements and the menter mserts ta S statements m the software at tagging 

instrumentation data; and 30 locations causing respective tag statements to be executed 

a program memory containing instructions of the com- alon S with a Polity of function call statements, and 

puter program causing the target system to write at least wherein the tagging analyzer includes a call pair analyzer 

one tag to at least one predetermined location in an that determines which functions of the software are linked to 

address space of the target system during the execution other functions of the software based on the order in which 

of the computer program in the target system, the at 35 the probe captures the tags. 

least one tag containing a respective tag value corre- 19 sys tem of claim 18 wherein the call pair analyzer 

spending to a tagging location in the computer pro- compiles a statistical record of a relative frequency at which 

^™ m " r , . r . specific called functions are called by specific calling func- 

12. The system of claim 11, further comprising: ^ 

a probe that captures tags from the at least one predeter- 40 "J ^ m of daim u wherein ^ j instm . 

mined location while the target system executes the ' . . T 

, ° ' menter inserts the tagging statements into the computer 

computer program; and , ee ^ e „ r 

program when source code for the computer program is 

a tagging analyzer that receives the tags from the probe -i a 

and uses the received tag values as reference keys for C °!?P ™ ' r , . . . 

retrieving the instrumentation data associated with the 45 21 - Thc s y stem of claml 11 wherein the ia 2Z m Z msXnx ' 

executed tagging statements from the symbol database. meQter mserts the ta ggi n g statements into the computer 

13. The system of claim 12 wherein the tagging analyzer program before source code for the computer program is 
determines computer program locations that have been compiled. 

executed based upon the instrumentation data retrieved from 5Q 22. A system for determining and displaying the coverage 

the symbol database. of software being executed in a target system, the software 

14. The system of claim 12, further comprising: containing a plurality of executable tag statements which, 
a time tag generator connected to the probe, the time tag when executed, cause the target system to write a plurality 

generator recording respective times when the probe of respective tags to at least one location in an address space 

captures the tags from the target system, 55 of the target syste m, the respective tags containing respec- 

wherein the tagging analyzer determines the time required uVe tag values corresponding to locations in the software of 

for executing the software between first and second respective tag statements generating the respective tags, the 

locations based on the difference between first and system comprising: 

second times recorded when the probe captures first . ... . 4t _ t iL 

, , f ^ r r a probe communicating with the target system while the 

and second tags. 60 \ f 4 , - ,u L 

15. The system of claim 12 wherein at least some of the ! ar S et s y st ^ m exe ^ tes me software > th u e P robe ca P^ r " 
tags have a tag type field corresponding to an analysis m S la 8 s from the tar g et s y stem when executable 
function for which the tag is used, and wherein the tag respective tag statements are executed; 

analyzer processes the tags differently according to their a processor connected to the probe, the processor deter- 

respective analysis functions based on respective values in 65 mining software locations that have been executed 

the tag type field regardless of the location in the address based on the respective tag values of the captured tags 

space to which the tag is written. while the target system executes the software; and 
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a symbol database communicating software location data 
to the processor, the symbol database receiving from 
the processor the respective tag values of the captured 
tags, the processor using the respective tag values as 
reference keys for retrieving corresponding software 
location data. 

23. The system of claim 22 wherein the processor further 
determines a duration that the software executes a function 
in the software for each of a plurality of tasks calling the 
function based upon analysis of received tag values and 
software location data. 

24. The system of claim 22 wherein the processor utilizes 
the software location data from the symbol database to 
detect when the software is performing a function in one of 
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a plurality of tasks calling the function and alters its per- 
formance in response thereto. 

25. The system of claim 24 wherein the processor traces 
the execution of the software only when the processor 
determines from the software location data retrieved from 
the symbol database that the software is performing the 
function in the one of a plurality of tasks calling the function. 

26. The system of claim 24 wherein the processor uses the 
software location data from the symbol database to identify 

) a memory characteristic being allocated in the target system 
when the processor detects that the software is executing the 
function in the one of a plurality of tasks calling the function. 

***** 
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